Einleitung
Nachdem wir uns in einem früheren Artikel mit den Fähigkeiten beschäftigt haben, die Scrum Teams idealerweise haben sollen, wird es nun darum gehen, das Vorhandensein dieser Fähigkeiten bzw. des Wissens zu überprüfen. Dabei geht es auch darum, herauszufinden, wie dieses Wissen im Team verteilt ist. So sollen Wissensinseln und Wissensdefizite entdeckt werden. Zusätzlich werden dann noch Methoden vorgestellt, um Wissen zu transferieren damit mögliche Wissensinseln zu beseitigen.
Wir sollten zwischen Wissen, Fähigkeiten bzw. Know-how unterscheiden, welches jedes Teammitglied haben muss und welches nicht jedes Teammitglied haben muss. Bei ersterem können wir beispielsweise das Qualitätsbewusstsein und die Konfliktfähigkeit nennen. Nur wenn alle Teammitglieder möglichst optimal an den Anforderungen des Kunden arbeiten, kann das Team zusammenarbeiten und das gewünschte Produkt herstellen.
Zu zweiterem zählt das Konfliktmanagement. Bei diesem geht es um das Erkennen und Lösen von Konflikten. Das Lösen dieser, und die daraus resultierende Zusammenarbeit, hilft dabei bessere Ergebnisse zu erzielen.
Wissensinseln
Wissensinseln sind Wissen oder Fähigkeiten, welche nur 1-2 Personen im Team haben. Solche Wissensinseln stellen für das Team ein Risiko dar, denn fällt nun genau diese Person/Personen aus, so ist das Team handlungsunfähig und kann nicht mehr normal weiterarbeiten.
Skill Matrix
Um jetzt die Wissensengpässe zu identifizieren, können wir die Skill-Matrix nutzen. In dieser werden die Fähigkeiten der Mitarbeiter dargestellt. Somit können Stärken und Schwächen sowie ausbaufähige Skills veranschaulicht werden. Es ist damit möglich, Stellen zu identifizieren, an denen das Ausfallrisiko eines Teams am höchsten ist. In den Zeilen der Matrix werden die Fähigkeiten und das Wissen aufgeführt, während die Spalten die Namen der Personen enthalten. Der Wissensstand der Teammitglieder wird festgehalten, um einen Überblick über das Team zu haben.
Wichtig hierbei, dass nicht jeder Mitarbeite jedes Wissen und jede Fähigkeit besitzen muss. Das Ziel ist es, das Wissen breiter zu streuen und somit das Ausfallrisiko zu minimieren. In der Tabelle kann festgelegt werden, wie häufig und in welchem Level Wissen vorhanden sein soll. Diese gibt dann an, ab welcher Stufe das geforderte Wissen, erfüllt ist. Ein Beispiel dafür sehen wir in der Tabelle bei der Fähigkeit Projektmanagement. Dort sehen wir das 2 Personen gefordert sind und diese erst ab dem Level Experte gezählt werden.
Idealerweise gibt es eine Einheitsdefinition, allerdings benötigen unterschiedliche Fähigkeiten unterschiedliche Ausprägungen. Auch muss die Lesbarkeit der Tabelle beachtet werden. Somit kann diese Ausprägung entweder in der Tabelle stehen oder separat dokumentiert werden.
Anhand der Beispielmatrix sind die Mitglieder eines Scrum Teams zu erkennen, sowie deren Wissensstand in den verschiedenen Bereichen. Unter der Spalte „Vorhanden“ ist zu sehen, wie viele Personen über das Wissen bereits verfügen und unter „Gefordert“, mit wie vielen Personen geplant wird. Bei der Personenanzahl für die „Gefordert“ Spalte sollten wir immer an ein Worst-Case-Szenario denken und schauen, dass das Team weiterarbeiten kann. Hier muss das Team entscheiden, ab welchem Wissensstand eine Person mitgezählt werden kann.
Gleichzeitig ist es wichtig, dass nicht jedes Teammitglied alles wissen muss. Ein weiterer Punkt ist sich als Team zu überlegen, ab welcher Stufe eine Person mitgezählt wird. Das sollte das Team entscheiden und so auf aktuelle und zukünftige Anforderungen reagieren. Hierbei sehen wir direkt, dass die Teamarbeit und die analytischen Fähigkeiten noch ausgebaut werden müssen.
Bei der Bewertung der Fähigkeiten gibt es verschiedene Möglichkeiten. Die Fähigkeiten können wie hier mit „Grundkenntnisse“, „Fortgeschritten“ und „Experte“ gekennzeichnet werden. Es ist aber auch möglich eine Skala von z.B. 1-10 zu nutzen. Dabei muss dann Transparent gemacht werden, welche Zahl für welche Stufe steht. Bleiben wir aber bei der Einteilung, welche in der Tabelle verwendet wurde. Eine Definition wie die Stufen definiert sind, könnte lauten:
- Anfänger: Ein Anfänger ist eine Person, die neu in einem bestimmten Bereich ist und wenig oder keine Erfahrung oder Kenntnisse in diesem Bereich hat. Anfänger benötigen Anleitung und Hilfe, um grundlegende Fähigkeiten und Kenntnisse zu erlernen, und sie machen häufig Fehler, da sie sich noch nicht mit der Materie vertraut gemacht haben.
- Fortgeschrittener: Ein Fortgeschrittener ist eine Person, die über grundlegende Kenntnisse und Fähigkeiten in einem bestimmten Bereich verfügt und in der Lage ist, selbstständig zu arbeiten. Sie hat bereits einige Erfahrungen gesammelt und kann schwierigere Aufgaben bewältigen. Fortgeschrittene benötigen jedoch manchmal noch Anleitung oder Unterstützung, um ihre Fähigkeiten weiter zu verbessern.
- Experte: Ein Experte ist eine Person, die über umfassende Kenntnisse, Erfahrungen und Fähigkeiten in einem bestimmten Bereich verfügt. Experten können komplexe Probleme bewältigen und sind in der Lage, innovative Lösungen zu finden. Sie können auch anderen helfen, ihre Fähigkeiten zu verbessern und ihr Wissen zu erweitern. Experten haben in der Regel viele Jahre in einem bestimmten Bereich gearbeitet und verfügen über eine breite und tiefe Expertise.
Es gib eine Vielzahl von Möglichkeiten, die Fähigkeiten zu bewerten. Nutzt die Methode, welche am besten für euch passt. Das Gleiche gilt für die Fähigkeiten, die verglichen werden, dies sind hier nur Beispiele und sollen euch helfen das Konzept schneller und einfacher zu verstehen.
Truck-Faktor-Analyse
Die Truck-Faktor-Analyse ist ein leichtgewichtiger Ansatz, um den Einfluss von einzelnen Personen auf das Projekt zu verdeutlichen. Dabei wird die Frage gestellt: „Was sind die Auswirkungen für das Projekt, wenn ein Mitarbeiter von einem LKW erfasst wurde und deswegen überraschend und dauerhaft ausfällt?“ Diese bietet uns eine personenbezogene Analyse an, wodurch Fähigkeiten identifiziert werden, welche wichtig sind und eventuell noch nicht erfasst wurden.
Wissenstransfer
Nun haben wir unsere möglichen Wissensinseln identifiziert und wissen, welche Mitarbeiter über welche Fähigkeiten, Wissen oder Know-how verfügen. Im nächsten Schritt geht es darum, dass Wissen den anderen Teammitgliedern zugänglich zu machen.
Dokumentation
Eine Möglichkeit ist die Dokumentation. Bei dieser geht es darum, alle Aufgaben und Prozesse, die als Wissensinseln identifiziert wurden, zu dokumentieren und zu kommentieren. Somit können andere Personen ein Verständnis aufbauen den Prozess bzw. die Aufgabe zu verstehen und eigenständig durchführen zu können. In der Softwareentwicklung kann dies bedeuten, den Programmcode zu kommentieren und somit die einzelnen Funktionen einfach und schnell zu erklären. Größere Zusammenhänge wie die Architektur, können in UML-Diagrammen oder in einem Architekturdokument beschrieben werden.
Dabei gibt es verschiedene Nachteile. Zum einen verrottet so eine Dokumentation und kann somit nach einer gewissen Zeit unbrauchbar werden.. Das Format spielt hierbei eine wichtige Rolle. Wenn die Dokumentation den Programmcode nur erklärt und somit die Informationen des Programmcodes in anderer Form widerspiegeln, so ist die Information redundant. Erklärt die Dokumentation weitere Zusammenhänge, Abläufe und Entscheidungen, so ist die Dokumentation hilfreich.
Egal ob die Dokumentation redundant ist oder nicht, bei jeder Veränderung besteht das Risiko, dass diese Veränderung nicht in der Dokumentation angepasst wird. Es gibt also ein grundsätzliches Problem, dass eine Veränderung nicht nachgehalten wird und es somit eine Abweichung zwischen Programmcode und Dokumentation vorhanden ist. Geht es um Wissen, welches nur ein Mitarbeiter hat und dieses ist nicht in anderer Form festgehalten, so ist die Dokumentation eine gute Idee, um das Wissen zu verbreiten bzw. festzuhalten.
Pair Programming
Das Pair Programming ist ein Teil des Extreme Programming. Beim Pair-Programming sitzen zwei Entwickler zusammen und bearbeiten gemeinsam eine Aufgabe. Dabei gibt ein Entwickler den Code ein, während der andere beobachtet, Feedback gibt und Fragen stellt, also mit dem anderen interagiert. Nach ungefähr 5-10 Minuten werden die Rollen gewechselt. Durch diese Zusammenarbeit ist es möglich, potenzielle Fehler und Probleme frühzeitig zu erkennen.
Aufgrund dieser Zusammenarbeit entstehen einige Vorteile:
- Es entsteht eine bessere Code-Qualität, da die beiden Entwickler zusammenarbeiten und Feedback geben können.
- Beim Pair-Programming entsteht ein Wissensaustausch, dabei werden Erfahrungen, Wissen und Know-how weitergegeben, wodurch Wissensinseln aufgelöst werden.
- Es werden schneller Probleme identifiziert und gelöst.
Leider gibt es auch ein paar Nachteile, die angesprochen werden müssen:
- Beim Pair-Programming müssen zwei Entwickler an einer Aufgabe arbeiten, was, zumindest in einer kurzen Betrachtungsweise, mit höheren Kosten verbunden ist. Langfristig spart das Pair-Programming Zeit ein, da der Programmcode eine höhere Qualität besitzt und somit ein reduzierter Aufwand für das Bug-Fixing und die Weiterentwicklung entsteht.
- Durch unterschiedliche Arbeitsweisen kann es zu Konflikten führen, welche die Produktivität kurzfristig beeinflussen Zuerst müssen beide Entwickler lernen, wann der beste Zeitpunkt ist, nachzufragen. Auch ist es wichtig zu erkennen, dass diese Nachfragen wertvoll sind und dadurch die Zusammenarbeit verbessert wird.
Langfristig sorgt das Pair Programming für eine bessere Zusammenarbeit im Team, da die Teammitglieder die unterschiedlichen Arbeitsweisen kennenlernen. Das Konzept des Pair-Programming kann auch auf andere Tätigkeiten übertragen werden, dazu zählen das generelle Lernen, die Problemlösung, Marketing oder Design. Bei allen diesen Tätigkeiten, sitzen zwei Personen zusammen, um die Aufgabe schneller zu lösen bzw. ein besseres Ergebnis zu erzielen.
Rotation der Aufgaben
Unter der Rotation der Aufgabe verstehen wir, dass die Mitarbeiter regelmäßig Ihre Tätigkeitsbereiche wechseln. Das meint bei Scrum, dass immer verschiedene Mitarbeiter beispielsweise das Front-End entwickeln und dadurch die Entstehung von Wissensinseln direkt vermieden wird. Es wird also darauf geachtet, dass die Mitarbeiter verschiedene Kompetenzen entwickeln.
Durch die Rotation können Mitarbeiter ein breiteres Wissen und Verständnis für verschiedene Bereiche entwickeln, es wird also das Risiko von Wissensinseln verringert. Es gibt auch Nachteile bei einer möglichen Rotation.
Zum einen brauchen Mitarbeiter eventuell länger für die Erledigung von Aufgaben da Ihnen die Routine bei der Durchführung fehlt. Es kann zu Kompetenzverlust führen, da Mitarbeiter über eine gewisse Zeit die Aufgabe nicht ausführen können und somit mehr Zeit in der Einarbeitung benötigen. Generell muss auch der Planungsaufwand berücksichtigt werden. Die Rotation von Aufgaben muss sorgfältig geplant werden, damit das Projekt nicht beeinträchtigt wird.
Die Rotation der Aufgaben lässt sich sehr gut mit dem Pair-Programming verbinden, da eine routinierte Person mit einer nicht erfahrenen Person zusammenarbeitet und viele Nachteile ausgleicht. Gleichzeitig gibt es durch diesen gemeinsamen Ansatz selbst Vor- und Nachteile, welche berücksichtigt werden müssen. Die Rotation der Aufgaben sollte insgesamt als Investition in die Zukunft gesehen werden.
In Scrum gibt es zwei Events, welche dazu beitragen, dass Wissen vermittelt und verteilt wird. Dazu zählen:
- Daily Scrum
Bei dem Daily Scrum, kommt das gesamte Scrum-Team zusammen, um sich über den Fortschritt und Probleme auszutauschen. Hier wird kein ausführlicher Wissenstransfer stattfinden können, allein schon wegen der 15-minütigen Timebox. Daher wird hier ein eventuell notwendiger Wissenstransfer identifiziert und organisiert. Es können anschließend sogenannten Meet-Afters stattfinden, in denen sich die angesprochenen Personen treffen und das Vorgehen beim Wissenstransfer besprechen können.
- Sprint Retrospektive
Bei der Sprint Retrospektive geht es darum, dass sich das Team über den vergangenen Sprint austauscht. Hier besteht die Möglichkeit Best Practices und Verbesserungsvorschläge auszutauschen oder auch neue Vorgehen zu besprechen. Durch die Ableitung von Problemen, kann herausgefunden werden, warum es ein Problem gab. Hierbei können auch Wissensinseln identifiziert und angegangen werden. Durch diese Überprüfung kann auch die Skill-Matrix immer wieder ergänzt und erweitert werden.
Wir sehen also, es gibt verschiedene Arten, um Wissensinseln aufzulösen. Diese müssen allerdings zielgerichtet eingesetzt werden, um auch einen Nutzen für das Projekt zu generieren. Jetzt bist du dran, identifiziert doch Wissensinseln in eurem Team und versucht diese aufzulösen. Denkt daran, das Auflösen von Wissensinseln kann länger dauern, hilft eurem Projekt allerdings langfristig.