Wir alle wissen wie wichtig ein gesunder und lebendiger Wissenstransfer innerhalb unserer Teams ist, manchmal gestaltet sich das jedoch als schwierig. Immer wieder begegnen uns Einzelkämpfer die wenig bis gar nichts von Pair Programming halten (versuchen Sie die mal zum Mob Programming zu überreden), oder die Unterschiede im Team sind so groß, dass ein Pair überhaupt keinen Sinn hat. Wie gehen wir also mit dieser Situation um?
Man spricht gern davon, dass der Idealzustand so aussehe, dass alle im Team alles können sollten. Das ist meiner Meinung nach kompletter Blödsinn, wenn wir uns um Featureteams bemühen. Der Designer kann herzlich wenig mit dem Know How des Datenbankexperten anfangen.
Der Wahrheit etwas näher kommen wir mit dem Begriff vom generalisierten Spezialisten bzw. vom spezialisierten Generalisten. Ich überlasse Ihnen dabei gern die Entscheidung, was Ihnen lieber ist. Im Endeffekt läuft es darauf hinaus, dass man ein Spezialgebiet hat, in dem man richtig stark ist und sich echtes Expertenwissen angeeignet hat, und angrenzende Gebiete, in denen man sich vernünftig bewegen kann. Im Featureteam würde das z.B. bedeuten, dass der Designer auch durchaus Einiges über Frontend-Entwicklung weiß, aber eben nicht so viel wie unser Frontender. Der wiederum kann im Zweifelsfall auch mal ein paar kleinere Grafiken in Photoshop basteln, wenn unser Designer gerade Urlaub hat.
Unser Ziel ist zunächst einmal die Vermeidung von Exklusivwissen. Wir könnten es uns dann einfach nicht erlauben, dass eben diese Person einen freien Tag hat. Könnte jede Aufgabe im Team im Zweifel von zwei unterschiedlichen Personen erledigt werden (eben von dem, in dessen Heimatbereich die Sache fällt, und von dem, der diesem benachbart ist), sind wir schon wesentlich sicherer. Das gibt unseren lieben Kollegen zumindest die Möglichkeit, einmal ein paar Tage Urlaub zu nehmen.
Wenn wir ein breit gefächertes Team mit allen Typen zwischen Deep-Core-Entwickler und Designer vor uns haben, dann liegt die erste Schwierigkeit darin, unser gesamtes Team von der Notwendigkeit des Wissenstransfers zu überzeugen. Das ist jedoch nur selten ein Problem. Einen Teil seines Wissens gibt man gern Preis, und jeder wird verstehen, dass es ein Unding ist, der einzige in einem Team zu sein, der eine Aufgabe erledigen kann.
Ein viel größeres Problem haben wir, wenn sehr seniorige Kollegen ihr projektbezogenes Know How an sehr juniorige Kollegen weitergeben müssen. Wenn sich bisher ausschließlich ein Senior um z.B. Merge & Deploy gekümmert hat, jetzt jedoch ein Junior diese Aufgabe ggf. auch einmal übernehmen muss (weil wir einfach nicht besonders viele Senioren haben), dann müssen wir zunächst einmal die allgemeine Wissenslücke zwischen diesen beiden schließen, bevor wir uns um die projektbezogene spezifische Wissenslücke kümmern können.
Das Allgemeine können wir im Zweifel mit externen Schulungen erschlagen. Der Wissenstransfer im Team ist nur bedingt eine Fortführung der Ausbildung oder des Studiums. Dabei ginge es um allgemeinverfügbares Wissen, das man aus vielen Quellen beziehen kann. Viel wichtiger ist der projektbezogene Wissenstransfer. Dies können wir selbstverständlich nicht mit einer Schulung erledigen.
Für die allgemeine Weiterbildung eines Entwicklers erwarte ich ein wenig Eigeninitiative. Zusätzlich bin ich auch gern dazu bereit, Raum für Schulungen während der Arbeitszeit zu geben, gegenseitige Schulungen zu unterstützen usw., das ist im Moment jedoch nicht der Punkt. Mich interessiert die Frage, wie ich das hochspezialisierte Wissen aus dem einen Kopf in den anderen bekomme.
Gehen wir davon aus, dass wir den juniorigen Kollegen über allgemeine Schulungen soweit bekommen haben, dass er in der Lage wäre, das spezialisierte Wissen aufzunehmen. Unser erster Gedanke ist jetzt wahrscheinlich Pair Programming, in dem ein erfahrener Kollege den Junior an die Hand nimmt. Auch wenn das ein guter Weg ist. Auch wenn das ein guter Weg ist, so ist nicht jeder Mensch für Pair Programming geeignet. Viele Entwickler lehnen das einfach ab und verweigern sich dann komplett. Manchmal läuft es so, dass einer einfach alles in die Tastatur hackt, während der andere nur zusehen kann und nichts versteht, weil auch nicht viel erklärt wird. Wenn also Pair Programming, dann richtig. Mit viel Gespräch und Erklärung.
Ist in ihrem Team die Bereitschaft zum Pair vorhanden, es funktioniert aber nicht richtig, weil es ein eher ungewohntes Vorgehen ist, dann haben Sie einfach ein wenig Geduld. Reflektieren Sie mit den Beteiligten mit ein wenig Abstand über die abgelaufene Session. Das läuft wie eine Art Mini-Retrospektive. Was ist gut gelaufen? Was ist schlecht gelaufen, und was muss man anders machen? Die Sache wird sich nach ein paar Versuchen eingespielt haben.
Ist das Pair keine Option, dann kann es ein Weg sein, den Senior zum Paten des Juniors zu machen. Man überträgt dem jungen Kollegen einfach die Aufgabe du lässt ihn loslaufen. Das ist sogar bei Merge & Deploy möglich, wenn sichergestellt ist, dass alles wieder rückgängig gemacht werden kann, und dass nichts live geht, das vom Paten nicht abgenommen wurde. Der Junior kann allein loslegen und sich an den Paten wenden, wenn er nicht weiter kommt. Dieser hilft dann an dieser Stelle aus und zieht sich dann wieder zurück. Auch dies erfordert natürlich die Bereitschaft des seniorigen Kollegen. Im allgemeinen ist die aber leichter zu bekommen als die zum Pair Programming.
Bleibt letztlich nur noch der Verweigerer. Zum Glück gibt es davon zwar nicht zu viele, aber sie sind noch lange nicht selten genug. Jemand hat die Meinung, dass sein exklusives Wissen ihn unentbehrlich macht oder zumindest seinen Marktwert erhöht. Beim Verweigerer begegnet uns ein archaisches Denken. Es geht darum, sein Revier zu markieren und das Alphamännchen zu sein. Ich muss gestehen, dass ich dann wenig Mitleid habe und dem Kollegen gern klar mache, dass gerade dieses Verhalten ihn besonders entbehrlich macht, weil ich eben genau diese Denkweise nicht in meinem Team haben will.
Selbstverständlich beginne ich aber mit dem Werkzeug des Gesprächs und der Argumentation. Manchmal hilft schon die Frage, was das Team machen soll, wenn der Kollege mal nicht da ist. Fragen Sie ihn, warum er sein Wissen nicht teilen will. Vielleicht offenbart sich dabei die Angst entbehrlich zu werden. Die Verweigerungshaltung ist oft genug auch eine Verteidigungshaltung. Das ist häufiger bei älteren Kollegen der Fall. Es ist jedoch nicht das exklusive Wissen, was ihn so wertvoll macht, sondern seine Möglichkeiten, jüngere Kollegen weiterzubringen.
Wenn alles nicht hilft, dann muss ihr verhindertes Alphamännchen eben eine Dokumentation schreiben, und Sie fragen die Junioren, ob das verständlich ist. Manchmal muss man leider Druck aufbauen und den Weg der Autorität gehen, auch wenn das nur unsere letzte Option ist.
Damit ist das Thema Wissenstransfer jedoch noch lange nicht erledigt. Sehr oft beschäftigt man sich damit, weil man mit der Nase darauf gestoßen wird. Eine Aufgabe konnte nicht erledigt werden, weil es eben nur einen im Team gibt, der es könnte, der war jedoch nicht da. Darauf reagiert man und sorgt dafür, dass genau diese Sache in Zukunft auch von einem anderen erledigt werden könnte.
Ich muss Ihnen nicht sagen, dass das nicht reicht. Sie wissen das sicherlich, aber dennoch handelt man meistens so, weil man mit dem Projekt vorankommen will. Man packt sich seine Sprints voll, die Geschäftsleitung will Ergebnisse sehen. Das Thema wird nach hinten verschoben und gerät in Vergessenheit.
Erst wenn wir ständig überprüfen, wo noch Engstellen sitzen, und wir uns das zur Gewohnheit gemacht haben, dann können wir davon sprechen, ein Problem weniger zu haben. Schulungen und Analysen gehören ebenso in die Planung wie die Umsetzung von Features. Meinetwegen packt sie auch ins Backlog. Wichtig ist nur, dass es nicht vergessen wird und man sich selbst immer wieder daran erinnert.
